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Abstract 

The  need  of  constraining  the  temporal  relationships 
among  sets  of  related  events  arises  in  several  tempo¬ 
ral  reasoning  tasks ,  including  monitoring ,  plan  vali¬ 
dation,  planning,  and  diagnosis.  Process  constructors 
provide  an  effective  way  of  packaging  up  related  events 
into  individual  conceptual  chunks,  called  macro-events. 
In  this  paper,  we  present  a  first  attempt  at  defining 
a  Calculus  of  Macro-Events  that  extends  Kowalski  and 
S ergot’s  Event  Calculus  with  process  constructors  to  ex¬ 
press  effects  triggered  by  complex  combinations  of  event 
occurrences.  We  apply  this  language  to  model  the  op¬ 
erations  of  a  simple  gas  heater,  and  present  a  Prolog 
implementation. 


1  Introduction 

Classical  formalisms  for  reasoning  about  actions  and 
change  make  the  simplifying  assumptions  that  (i)  only 
one  action  can  be  performed  at  any  given  time  (some 
formalisms  actually  allow  simultaneous  actions  under 
the  assumption  that  they  do  not  influence  each  other) , 
and  (ii)  actions  are  instantaneous.  When  we  remove 
the  first  assumption,  we  must  take  into  account  that 
concurrent  actions  may  interact.  Interactions  may  lead 
both  to  synergistic  results  (their  combined  effect  is 
more  than  the  sum  of  their  individual  outcomes)  and  to 
interferences  (their  individual  effects  may  be  partially 
or  totally  canceled).  For  example  [2],  if  one  agent  lifts 
one  end  of  a  piano,  while  another  agent  lifts  the  other 
end,  then  the  entire  piano  is  lifted  off  the  floor;  instead, 
if  one  agent  pushes  a  door  open,  while  the  other  is  push¬ 
ing  it  closed,  the  two  actions  cancel  each  other  out.  To 
handle  these  situations,  many  formalisms  support  ex- 
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plicit  axioms  to  model  interaction  among  concurrent 
actions,  e.g.  [4,  5,  13,  14,  18,  23,  26].  If  we  also  re¬ 
move  the  assumption  that  actions  are  instantaneous, 
occurrences  of  actions  may  partially  overlap  which  can 
influence  the  outcome  of  the  interacting  actions  [20] . 

However,  the  ability  of  dealing  with  concurrent 
and/or  temporally  extended  actions  is  not  sufficient 
for  many  realistic  applications.  Modeling  real-world 
domains  may  indeed  require  representing  complex  pat¬ 
terns  of  actions,  which,  besides  sequentiality  and  con¬ 
currency,  involve  additional  relations  among  actions, 
such  as  the  occurrence  of  just  one  action  in  a  given  set, 
the  iteration  of  occurrences  of  the  same  action  or  of  a 
pattern  of  actions.  The  notion  of  process  has  been  in¬ 
troduced  to  define  compound  actions  in  terms  of  pat¬ 
terns  of  simpler  actions.  As  an  example,  the  action 
of  dialing  a  ten-digit  number  can  be  defined  as  a  set 
of  ten  basic  actions  in  strict  sequence.  Foundational 
work  on  process  modeling,  which  inspired  research  in 
many  Computer  Science  areas,  including  knowledge 
representation,  has  been  done  by  Hoare  [15]  and  Mil¬ 
ner  [21].  Limited  contributions  to  (discrete)  process 
modeling  in  the  temporal  representation  and  reason¬ 
ing  area  have  been  proposed  by  Evans  [12],  Belegrinos 
and  Georgeff  [6],  Lesperance  et  al.  [17],  and  by  Lin  and 
Dean  [19]. 

In  this  paper,  we  present  preliminary  results  on  the 
definition  of  a  Macro-Event  Calculus,  an  extension  of 
Kowalski  and  Sergot’s  Event  Calculus,  EC  [16].  Our 
proposal  allows  expressing  basic  forms  of  process  inter¬ 
action,  including  temporal  delays  between  processes, 
sequential,  simultaneous,  and  alternative  occurrences 
of  processes,  and  process  iteration.  This  proposal 
builds  on  work  by  Cliittaro  and  Montanari  [10]  on  mod¬ 
eling  discrete  processes.  The  set  of  constructors  of  the 
current  version  of  the  Macro-Event  Calculus  is  similar 
to  the  path  expression  operators  of  [3].  Originally  de¬ 
veloped  for  modeling  operating  system  behavior,  path 
expressions  have  been  successfully  used  in  several  areas 
of  Computer  Science.  In  this  paper,  we  show  how  their 
formalization  within  the  Event  Calculus  can  be  usefully 
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Figure  1.  The  Gas  Heater:  a  User’s  Perspective 


employed  to  reason  about  complex  events.  Compared 
to  other  approaches  to  the  formalization  of  processes  in 
temporal  reasoning,  our  proposal  is  characterized  by  a 
logical  bias:  we  aim  at  developing  a  calculus  that  gives 
a  logical  meaning  to  constructs  which  are  operational 
in  nature.  We  reconcile  the  two  views  by  providing  a 
logic  programming  implementation  of  the  Macro-Event 
Calculus. 

The  paper  is  organized  as  follows:  in  Section  2,  we 
describe  the  Gas  Heater  Problem,  that  we  will  use  as 
our  case  study  throughout  this  paper.  In  Section  3 
we  formalize  versions  of  the  Event  Calculus  that  allow 
explicit  time  and  event  durations.  In  Section  4,  we 
define  macro-events  and  extend  our  specification  of  EC 
to  handle  them.  We  give  a  Prolog  implementation  of 
these  various  calculi  in  Section  5,  and  outline  directions 
of  future  work  in  Section  6. 

2  Case  Study 

We  will  illustrate  the  use  of  EC  and  of  the  pro¬ 
posed  extensions  by  modeling  some  of  the  operations 
of  a  simple  gas  heater  [10].  We  now  give  an  infor¬ 
mal  description  of  this  case  study,  and  later  formalize 
it  as  we  introduce  concepts  and  definitions.  In  [22], 
we  have  successfully  applied  a  variant  of  the  Macro- 
Event  Calculus  to  a  larger-scale  example,  the  Dagstuhl 
Steam-Boiler  problem  [1], 

The  gas  heater  presents  to  its  user  an  interface 
(shown  in  Figure  1)  consisting  of  two  buttons  ( Safety 
Disable  and  Lighter )  which  must  be  used  during  the 


system  start  up  procedure,  a  switch  (Power)  used  to 
enable  or  disable  system  operation,  a  knob  ( Desired 
Temperature)  used  to  select  the  desired  temperature 
for  the  environment  where  the  gas  heater  is  placed,  a 
tap  ( Gas  Main)  used  to  allow  or  prevent  the  supply 
of  gas  to  the  heater  and  a  plug  to  supply  electricity  to 
the  heater.  The  user  typically  starts  up  the  system  by: 
connecting  the  plug  to  a  socket,  opening  the  Gas  Main 
tap,  turning  on  the  Power  switch,  pressing  the  Safety 
Disable  button  together  with  the  Lighter  button  and 
keeping  them  pressed  until  he/she  sees  the  pilot  light 
turning  on,  releasing  then  the  two  buttons.  When  the 
pilot  light  is  on,  heating  is  automatically  controlled  by 
the  system,  which  burns  gas  when  the  room  tempera¬ 
ture  is  lower  than  desired  and  keeps  only  the  pilot  light 
on  otherwise  (details  below). 

Looking  inside  the  gas  heater  (Figure  2),  six  main 
components  deserve  attention.  The  Power  Switch  al¬ 
lows  or  prevents  the  supply  of  electrical  power  to  the 
Thermostat  and  to  the  Lighter  System.  The  Lighter 
System  is  devoted  to  producing  sparks  in  order  to  light 
up  the  pilot  light  during  the  start  up  procedure.  The 
Safety  System  prevents  dangerous  gas  leaks  into  the 
environment:  this  thermo-mechanical  device  closes  the 
Safety  Valve  when  it  is  not  heated  by  the  pilot  light 
and  opens  it  when  the  pilot  light  is  on.  If  the  Safety 
Disable  button  is  pressed,  the  Safety  Valve  allows  gas 
to  flow  through  the  pipe  connected  to  the  pilot  light 
(thus  allowing,  if  needed,  to  ignite  the  pilot  light  with 
the  Lighter)  but  not  through  the  pipe  connected  to 
the  Thermostatic  Valve.  The  Thermostat  senses  room 
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Figure  2.  The  Gas  Heater:  an  Engineer’s  Perspective 


temperature  and  opens  the  Thermostatic  Valve  if  the 
temperature  is  one  degree  or  less  lower  than  the  Desired 
Temperature  preset  by  the  user;  it  closes  the  valve  when 
temperature  is  at  least  one  degree  higher  than  the  De¬ 
sired  Temperature.  When  both  the  Safety  Valve  and 
the  Thermostatic  Valve  are  open,  a  huge  quantity  of 
gas  is  allowed  to  reach  the  main  burner  and  be  burnt, 
possibly  ignited  by  the  pilot  light. 

3  Explicit  Time  and  Event  Duration 

We  will  now  introduce  the  flavors  of  EC  we  will 
consider  in  this  paper.  In  Section  3.1,  we  formalize 
EC  with  explicit  time.  In  Section  3.2,  we  extend  this 
model  to  admit  non-instantaneous  events.  Finally,  in 
Section  3.3,  we  apply  these  notions  to  our  case  study. 

3.1  Explicit  Time 

While  the  original  informal  presentation  of  the 
Event  Calculus  [16]  anchors  the  occurrence  of  instanta¬ 
neous  events  to  explicit  time  points,  recent  work  on  the 
formalization  of  EC  [7,  8,  9]  abstracted  the  time  line 
and  only  considered  events  that  are  ordered  relative  to 
one  another.  We  will  extend  this  definition  so  to  ad¬ 
mit  explicit  time.  We  will  operate  on  the  formulation 
in  [8],  that  embeds  preconditions. 

The  Event  Calculus  with  Explicit  Time  and  Instan¬ 
taneous  Events  { ECT )  aims  at  modeling  situations 
that  consist  of  a  set  of  events,  whose  occurrences  over 


time  have  the  effect  of  initiating  or  terminating  the  va¬ 
lidity  of  properties  when  given  preconditions  are  met. 
The  time-independent  aspects  of  a  situation  are  formal¬ 
ized  by  means  of  an  ECT- structure.  It  alters  the  notion 
of  PEC- structure  given  in  [8]  only  by  the  addition  of  a 
temporal  domain. 

Definition  3.1  ( ECT-structure ) 

A  structure  for  the  Event  Calculus  with  Explicit 
Time  (ECT-structure  for  short)  is  a  quintuple  E  = 
( E ,  P,  [•]•),  (•]•],  T)  such  that: 

•  E  =  {ei, . . . ,  en }  and  P  =  {pi, . . .  ,pm}  are  finite 
sets  of  event  types  and  properties,  respectively. 
Elements  of  2P  are  called  contexts  and  the  prop¬ 
erties  in  them  are  referred  to  as  preconditions. 

•  [•]•)  :Px2p->2£  and  (•]•]  :  P  x  2P  ->  2E  are 
respectively  the  initiating  and  terminating  map  of 
E.  For  every  property  p  €  P,  [p\C)  and  ( p\C ]  rep¬ 
resent  the  set  of  events  that  initiate  and  terminate 
p,  respectively,  in  case  all  preconditions  in  C  hold 
at  their  occurrence  time. 

•  The  temporal  domain  T  is  some  ordered  set 

(T,  -<).  In  our  implementation,  we  used  the  natu¬ 
ral  numbers  N  with  their  usual  ordering.  □ 

The  instance-specific  part  of  a  specification  is  captured 
through  the  following  notion  of  time- structure: 
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Definition  3.2  (  Time-structure ) 

Given  an  ECT-structure  PL  =  (E,  P.  [•]•),  {•]•],  T), 
a  time-structure  for  PL  is  a  set  T  C  E  x  T  of  event 
instances,  where  a  pair  (e,t)  G  T  expresses  the  fact 
that  an  event  of  type  e  has  occurred  at  time  t.  □ 


Given  the  formalization  of  a  situation  in  terms  of 
an  ECT- structure  and  a  time-structure,  ECT  provides 
means  to  check  whether  a  given  property  p  is  valid  at 
a  given  point  t  in  time  [predicate  holdsAt (p,t)  below]. 
This  problem  is  easily  reduced  to  the  determination  of 
the  maximal  validity  intervals ,  abbreviated  MVI,  over 
which  a  given  property  holds  [mvi(p,  t\ ,  to)] :  a  property 
p  holds  maximally  over  an  interval  \t\,  to]  if  i)  t\  -<  to, 
ii)  an  event  e  initiating  p  subject  to  preconditions  Ci 
has  occurred  at  t\  and  all  properties  in  C\  hold  at 
ii  [initiated,  ti)],  in)  dually,  an  event  e  terminating  p 
subject  to  preconditions  Co  has  occurred  at  to  and  all 
property  in  Co  hold  at  to  [terminate)/),  to],  and  iv)  p  is 
not  initiated  or  terminated  at  any  time  point  between 
ti  and  to  [-ibroken(p, ti,t2)]. 


Definition  3.3  ( ECT-model ) 

Let  PL  =  (E,  P ,  [•]•),  (•]•],  T)  be  a  ECT-structure 
and  T  be  a  time-structure  over  PL.  We  define  the  fol¬ 
lowing  recursive  predicates: 


holdsAt(p,  t) 


mvi(p,  ti ,  to) 


initiate)/?,  t) 


terminate)/?,  t) 


iff  3ti ,  t2  G  T.  t\  •<  t  -<  to  A 
mvi)/?,  <1,  to) 

iff  ti  A  to  A  initiate)/?,  ti)  A 

terminate)/?,  to)  A  -i broken (p,  ti ,  to) 

iff  Be  G  E.  BC  G  2P .  (,./)  G  T  A 
p  G  [e|C)  A  \/q  G  C.  holdsAt (q,t) 

iff  Be  G  E.  BC  G  2P .  (e,t)  G  T  A 
p  G  (e|C]  A  \/q  G  C.  holdsAt(g,  t) 


broken (p,  ti ,  to)  ijff  3f  G  T.  ti  — <  t  A  t  -<  t2  A 

(initiate)/?,  t)  V  terminate)/?,  t)).  □ 


The  meta-predicates  holdsAt,  mvi,  initiate,  terminate 
and  broken  are  mutually  recursive  in  the  above  defini¬ 
tion.  In  particular,  an  attempt  at  checking  properties 
or  computing  MVIs  by  simply  unfolding  their  defini¬ 
tion  is  non-terminating  in  pathological  situations  [8]. 
However,  most  ECT  problems  encountered  in  practice 
satisfy  syntactic  conditions  ensuring  the  termination  of 
this  procedure.  See  [8]  for  a  detailed  discussion  of  these 
restrictions. 

The  above  definition  can  be  directly  transcribed  in 
the  programming  language  Prolog  [25].  The  resulting 
code  is  given  in  Section  5.1. 


3.2  Event  Duration 

Although  thinking  of  events  as  instantaneous  is  a 
sufficient  abstraction  for  some  situations,  in  many  cases 
the  occurrence  of  an  event  happens  over  a  period  of 
time  [24],  Capturing  this  possibility  enables  finer  mod¬ 
els,  as  we  can  now  reason  about  changes  that  take  place 
while  an  event  is  in  the  process  of  occurring.  In  par¬ 
ticular,  we  must  revise  our  notion  of  precondition  as  it 
can  now  have  at  least  two  meanings:  a  property  that 
should  hold  in  order  for  an  event  to  start  happening,  or 
a  property  that  ought  to  be  uninterruptedly  valid  dur¬ 
ing  the  entire  duration  of  the  occurrence  of  an  event. 
In  our  formalization  below,  we  will  allow  both  options, 
keeping  the  name  precondition  for  the  former,  and  call¬ 
ing  the  latter  constraint  [10]. 

Definition  3.4  (ECTD- structure) 

A  structure  for  the  Event  Calculus  with  Event  Du¬ 
ration  ( EC  TI)  structure  for  short)  is  a  sextuple  PL  = 
(E,  P,  [j-|-),  (•  | •  | •] ,  T,  S)  such  that: 

•  E  and  P  are  the  sets  of  event  types  and  properties , 
respectively. 

•  [-\-\-):  Px2px2p  -A  2e  and  (•] •  ]•]:  Px2px2p  — > 
2e  are  respectively  the  initiating  and  terminating 
map  of  PL.  For  every  property  p  G  P,  [/?|Cj/\)  and 
)/?|CjA']  represent  the  set  of  events  that  initiate 
and  terminate  p,  respectively,  in  case  all  precon¬ 
ditions  in  C  hold  at  the  time  they  start  occurring, 
and  all  constraints  in  K  hold  for  the  entire  dura¬ 
tion  of  their  occurrence. 

•  T  =  (T,-<,+,0)  is  the  temporal  domain,  where 
the  ordered  set  (T,  -<)  considered  above  is  aug¬ 
mented  with  a  monoid  component  (T, +,0). 

•  6  :  E  — »•  T  is  a  duration  function,  that  gives  the 

duration  of  every  event  type.  □ 

Observe  that  ECT- structures  are  degenerate  ECTD- 
structures  where  no  constraints  are  present,  and  6(e)  = 
0  for  every  event  e  G  E.  We  do  not  need  to  modify  the 
definition  of  time- structure. 

In  spite  of  the  drastic  changes  in  Definition  3.4  with 
respect  to  the  notion  of  ECT-structure,  the  modifica¬ 
tions  to  the  specification  of  how  to  check  whether  a 
property  holds  at  a  given  time  point  are  localized  to 
the  predicates  initiate  and  terminate.  Let  us  focus  on 
the  former:  in  order  for  initiate)/?,  t)  to  hold,  there  must 
be  an  event  e  with  preconditions  C  and  constraints  K 
that  initiates  /?.  If  e  starts  occurring  at  time  t' ,  it  must 
be  the  case  that  t  is  the  endpoint  of  the  occurrence 
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interval  of  e  ( i.e .  t  =  t'  +  6(e)).  Moreover,  every  pre¬ 
condition  in  G  must  hold  at  its  startpoint  t' ,  and  ev¬ 
ery  constraint  in  I\  must  be  valid  without  interruption 
throughout  the  interval  [t1  ,t\.  Notice  in  particular  that 
an  event  has  effectively  initated  a  property  at  the  end 
of  its  occurrence  interval.  Similar  considerations  ap¬ 
ply  to  the  case  of  terminate.  This  is  captured  in  the 
following  definition,  where  the  predicates  holdsDuring 
and  happens  are  accessory. 

Definition  3.5  ( ECTD-model ) 

Let  Li  =  (E,  P,  [•H-h  (-H-],  T,  6)  be  a  ECTD- 
structure  mid  T  be  a  time- structure  over  7 i.  We  modify 
Definition  3.3  by  overriding  the  specification  of  initiate 
and  terminate  given  there  with  the  clauses  below,  and 
adding  the  predicates  happens  and  holdsDuring. 

initiated,  i)  iff 

Be  G  /•:.  -/',<•/  G  T.  BC,K  G  2P . 

happens(e,  t' ,  cl)  A  t  =  t'  +  d  A 
p£[e\C\K)  A  \/q  G  C.  holdsAt(g,  t')  A 
Vg  G  K.  holdsDuring(g,f',f) 

terminate)^,  t)  iff 

Be  G  /•:.  Bt',d  G  T.  BC,I<  G  2P . 

happens(e,  t! ,  d)  A  t  =  t'  +  d  A 
p  £  (e\C\K]  A  Vg  G  C.  holdsAt(g,  t')  A 
Vg  G  K.  holdsDuring(g,f',t) 

happens(e,  t,  d)  iff  (e,t)  G  H  A  d  =  6(e) 

holdsDuring(p,  tu  to)  iff  Bt0,t3  e  T.  mvi(p,t0,t3)  A 

t0  <ti  A  to  V  t3 .  □ 

It  is  easy  to  verify  that,  whenever  Li  corresponds  to  an 
ECT-structure,  the  definition  reduces  to  Definition  3.1. 

It  is  interesting  to  observe  that,  in  the  absence  of 
constraints,  the  Event  Calculus  with  Event  Duration 
can  be  compiled  into  the  formalism  presented  in  Sec¬ 
tion  3.1.  Every  lasting  event  e  is  translated  into  a 
pair  of  instantaneous  events  start _e  and  encLe,  and  a 
property  occ_e.  Instances  (e,t)  are  mapped  to  the  in¬ 
stantaneous  instances  ( start-eft )  and  (encLe,  t  +  6(e)). 
Finally,  ifp  G  [e|(7|-),  we  get  occ_e  G  [start-e\C),  more¬ 
over  occ_e  G  (encLe]-],  finally  p  G  [encLe  ]•).  The  termi¬ 
nation  map  is  processed  analogously.  The  treatment 
of  constraints  is  problematic  because  of  the  require¬ 
ment  that  they  ought  not  to  be  interrupted  during  the 
event’s  occurrence  interval. 

Prolog  code  implementing  Definition  3.5  is  given  in 
Section  5.2. 


3.3  Example  —  Part  I 

The  first  phase  of  the  representation  of  the  gas 
heater  in  EC  consists  in  the  identification  of  the  rele¬ 
vant  types  of  events.  We  consider  eleven  types:  eight 
of  them  represent  possible  actions  of  the  user  of  the 
gas  heater,  i.e.  open  or  close  the  Main  Gas  tap  (gasOn, 
gasOff),  turn  on  or  off  the  Power  switch  (powerOn, 
powerOff),  press  or  release  the  Safety  Disable  button 
(prDisable,  relDisable),  and  press  or  release  the  Lighter 
button  (prLighter,  relLighter).  In  this  simple  model,  we 
will  not  represent  the  action  of  setting  the  Thermostat 
to  the  desired  temperature.  Two  other  types  of  event 
represent  the  possible  temperature  changes  in  the  en¬ 
vironment  as  reported  by  a  Thermometer  (cool Down, 
warm  Up).  In  order  to  represent  the  properties  that  are 
initially  valid  in  the  system  [11],  we  add  the  fictitious 
event  start  which  represent  the  beginning  of  time.  A 
possible  time  structure  T  built  using  the  above  types 
of  events  is  the  following: 


(start, 

0). 

(relDisable, 

6). 

(cool  Down, 

0). 

(warmUp, 

8). 

(gasOn, 

!)• 

(coolDown, 

10). 

(powerOn, 

2). 

(warmUp, 

11). 

(prDisable, 

3). 

(powerOff, 

18). 

(prLighter, 

3). 

(gasOff, 

19). 

(relLighter, 

5). 

(coolDown, 

25). 

In  this  scenario,  the  user  notices  a  drop  in  temperature 
(time  0)  and  takes  all  the  actions  needed  in  order  to 
ignite  the  pilot  light:  she  opens  the  Gas  Main  (time  1), 
switches  the  power  on  (time  2),  and  presses  the  Lighter 
and  Safety  Disable  buttons  simultaneously  (time  3). 
She  releases  these  buttons  at  time  5  and  6,  respectively. 
Between  time  8  and  11  the  thermometer  reports  some 
temperature  changes  in  the  environment.  At  time  18 
the  user  interrupts  the  supply  of  gas,  and  shortly  after 
she  turns  the  power  off.  Eventually,  the  rooms  becomes 
cold  again  (time  25). 

The  second  step  in  the  representation  of  the  gas 
heater  is  the  identification  of  the  interesting  prop¬ 
erties  that  are  initiated  and  terminated  by  events. 
We  model  this  system  by  means  of  nine  proper¬ 
ties:  whether  gas  is  flowing  into  the  heater  (gas), 
whether  electrical  power  is  supplied  (power),  whether 
the  room  is  cold  (cold),  whether  the  thermostatic 
and  the  safety  valves  are  open  (thermoVOpen  and 
safetyVOpen,  respectively),  whether  the  lighter  system 
produces  sparkles  (sparkling),  whether  the  pilot  light  is 
on  (pilotOn),  and  whether  gas  is  burning  in  the  main 
combustion  chamber  (burning).  Finally,  it  will  be  con¬ 
venient  to  know  when  the  pilot  light  is  off  (pilotOff). 

These  properties  fall  in  three  classes:  properties  ini- 
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tiated  or  terminated  by  the  simple  occurrence  of  an 
event;  properties  initiated  or  terminated  by  the  occur¬ 
rence  of  an  event  in  a  specific  context;  properties  initi¬ 
ated  or  terminated  by  a  combination  of  events. 

Properties  gas,  power,  cold,  and  thermoVOpen  fall  in 
the  first  class:  they  are  unconditionally  initiated  and 
terminated  by  the  events  gasOn  and  gasOff,  powerOn 
and  powerOff,  coolDown  and  warmUp,  and  coolDown 
and  warmUp,  respectively.  This  is  captured  in  EC  as 
follows: 


[§asl  'I') 

[power|  -  I-) 

[cold  |  •  |  •) 

[thermoVOpen  |  •  |-} 

<Sasl  'I'] 

(power|  -j-] 

(cold  •  •] 

(thermoVOpenj  •  |-] 


{gasOn}, 

{powerOn}, 

{coolDown}, 

{coolDown}, 

{gasOff} 

{powerOff} 

{warmUp} 

{warmUp} 


The  second  class  consists  of  the  properties  sparking 
and  safetyVOpen.  While  the  former  simply  requires 
that  power  be  supplied  when  the  lighter  button  is 
pressed,  the  latter  has  a  more  complex  behavior.  Con¬ 
sider  first  how  to  terminate  the  property  safetyVOpen: 
if  the  pilot  light  is  off,  releasing  the  safety  button  is 
sufficient  to  close  the  valve;  however  if  this  is  not  the 
case,  the  only  way  to  shut  the  safety  valve  is  by  extin¬ 
guishing  the  pilot  light,  which  is  achieved,  as  we  will 
see,  by  interrupting  the  supply  of  gas.  We  have  the 
following  formalization: 


[sparking|  •  (power) 
[safetyVOpen  |  •  |-) 

(sparking)  •  |  •] 
(safetyVOpen|  •  |pilotOn] 
(safetyVOpen  j  •  jpilotOff] 


{prLighter} 

{prDisable} 

{relLigher,  powerOff} 
{gasOff} 

{relDisable} 


The  remaining  properties  pilotOn  and  pilotOff, 
which  records  whether  the  pilot  light  is  on  or  off,  de¬ 
pends  on  constraints  such  as  the  availability  of  power 
and  gas.  However,  they  are  initiated  and  terminated 
respectively  by  the  simultaneous  occurrence  of  two 
events  (prDisabled  and  prLighter).  Similar  remarks  ap¬ 
ply  to  the  property  burning.  The  extensions  to  EC  we 
devised  so  far  are  insufficient  to  specify  these  situations. 


4  Event  Calculus  with  Macro-Events 


events.  We  will  address  this  shortcoming  of  ECTD  by 
allowing  the  validity  status  of  properties  to  be  changed 
on  the  basis  of  the  occurrence  of  structured  conglom¬ 
erations  of  events  that  we  will  call  macro-events.  In 
Section  4.1,  we  define  this  notion  and  extend  ECTD- 
structures  to  accommodate  it.  It  takes  into  account 
the  cumulative  effects  of  a  set  of  related  events,  but  for 
simplicity,  excludes  interference  issues.  In  Section  4.2, 
we  simultaneously  address  the  problems  of  determin¬ 
ing  whether  a  macro-event  has  occurred,  and  extend 
the  specification  of  validation  of  a  property  (Defini¬ 
tion  3.5)  to  these  entities.  In  Section  4.3,  we  complete 
the  treatment  of  our  case-study. 

4.1  Definition 


In  our  current  model,  macro-events  are  obtained  by 
considering  sequential,  alternative,  parallel,  or  iterated 
occurrences  of  elementary  events,  or  any  combination 
of  these  constructions. 


Definition  4.1  ( Macro-Events ) 

Given  a  set  of  events  E  and  a  temporal  domain 
T  =  (T,  — < ,  -U ,  0) ,  macro-events,  denoted  with  m  possi¬ 
bly  subscripted,  are  expressions  defined  by  the  following 
grammar: 


m 


e 

mi  m2 
mi  +  m2 
mi  1 1  m2 
m* 


(Basic  event ) 

( Sequence  with  delay  cl  to  D) 
( Alternative ) 

( Parallelism) 

( Iteration ) 


where  d,  D  €  T  and  d  <  D.  Let  Mr  be  the  set  of  the 
macro-events  over  T .  □ 


This  definition  formalizes  the  core  of  the  notion  of  pro¬ 
cess  studied  at  length  in  [10,  22],  which  in  turn  extends 
the  limited  notion  of  macro-events  (essentially  delayed 
sequencing)  presented  in  [12], 

The  constructors  we  included  in  this  language  are 
based  on  the  path  expression  operators  of  [3]  and  on 
the  process  calculi  operators  found  in  [15,  21].  Observe 
that  a  number  of  useful  constructs  are  easily  express¬ 
ible  with  the  language  in  Definition  4.1.  In  particu¬ 
lar  sequencing  with  arbitrary  delay  (;),  immediate  se¬ 
quencing  (;;),  non-empty  iteration  (•+)  and  fixed-length 
iteration  (•")  are  defined  as  follows  in  [22]: 


As  we  just  saw,  even  when  events  with  durations  are 
available,  EC  does  not  lend  itself  to  easily  expressing 
situations  where  properties  are  initiated  or  terminated 
not  by  single  events,  but  by  the  occurrence  of  multiple 


mi ;  m2  =  mi  ',o  m2 
ni+  =  m;m* 
mi;;  m2  =  mi  ;(]  m2 

m”  =  m; . . . ;  m  ( n  times) 
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me(e,  [t1,t-2],s,l) 

iff 

(e,s)  €  T  A  l  =  5(e)  A  [s,  s  +  l]  ■<  [t\,  f2] 

me(mi  m2)  [h,  f2]„  S,  l) 

iff 

Z:i,Z2  G  T.  me(mi,  [fi,  fi],s,/i)  A  me(ms,  [t'2,t-f\,  s2,  h) 

A 

s  +  l\  -<  t\  t'2  A  s2  A  s  +  l\  +  d  <  s-2  A  s  +  l\  +  D 

l  =  S2  +  1'2  —  !' 

A 

me(mi  +m2,  [ti,i2],s, /) 

iff 

me(nii,  [ti,  t2],  s,  l)  V  me(m2,  [G ,  t2],  s,  l) 

me(mi  m2,  [tuh^sj) 

iff 

3si,Zi,s2,Z2  €T.  me(mi ,  [£i , t2],  si ,  li)  A  m e(m2,  [fi,  f2],s2,  Z2) 

A 

s  =  min  (si ,  s2)  A  l  =  max(si  +  l\ ,  s2  +  h)  —  s 

m e(m*,  [fi,f2j,  s,  l ) 

iff 

UJ 

Co 

to 

m 

N 

Co 

II 

OK 

> 

II 

o 

< 

(me(m,[ti,t\,s,h)  A  me(m*,  [t,  t2],  s2 , /2)  A 

s  +  h  A  t  A  S-2  A  l  =  So  +1-2  ~  s ) 

Figure  3.  Definition  of  me 


Before  giving  the  exact  semantics  of  macro-events, 
we  update  our  formalization  of  ECTD  of  Section  3.2 
to  accomodate  these  entities.  The  changes  to  the  defi¬ 
nition  of  FCTD-structure  turn  out  to  be  very  modest. 

Definition  4.2  ( M ECTD- structure ) 

A  structure  for  the  Macro-Event  Calculus 
(MECTD-structure  for  short)  is  a  septuple 
n  =  (E,  P ,  M,  [-I-I-),  T,  S)  which  dif¬ 

fers  from  the  definition  of  ECTD -structure  only  by 
the  following  points: 

•  M  C  Mt  is  a  set  of  macro-events  over  T . 

•  The  codomain  o/[jj-)  and  {jj-j  are  redefined  to  be 
2M :  indeed  [-I'l-)  :  P  x  2P  x  2P  — >  2M  and  (-l-l-]  : 
P  x  2P  x  2P  — >  2M .  This  implies  that  properties 
can  be  started  and  ended  by  generic  macro-events, 
not  just  plain  events. 

•  We  assume  that  the  temporal  domain  (T,  -<)  has 

a  maximum  element  oo,  and  that  (T,  +  ,0)  is  a 
group,  with  —  the  inverse  operation  of  +.  □ 

Observe  that  we  did  not  propagate  the  change  to  the 
duration  function:  only  basic  events  are  explicitly  given 
a  duration  by  means  of  6.  The  duration  of  occurrences 
of  macro-events  will  instead  be  computed  on  the  basis 
of  their  structure  and  of  the  participating  basic  events. 

We  do  not  modify  our  notion  of  time-structure  T : 
only  elementary  events  are  recorded.  Occurrences  of 
macro-events  will  instead  be  inferred. 

4.2  Monitoring  and  Evaluation 

The  occurrence  of  a  macro-event  is  not  explicitely 
recorded,  but  must  be  determined  on  the  basis  of 
its  definition  and  of  the  time-structure  at  hand.  In 
order  to  do  so,  we  define  the  auxiliary  predicate 


me(m,  [t\,  f2],  s,  l),  which  verifies  whether  a  macro¬ 
event  m  has  occurred  over  the  interval  [ti,t2],  and,  if 
this  is  the  case,  computes  its  starting  point  s  and  dura¬ 
tion  l.  These  two  arguments  are  necessary  to  correctly 
process  the  bounds  of  a  delayed  sequence  of  events. 
Given  a  MECTD- structure  TL  =  ( E ,  P,  M,  [-l-l-), 
{•I'l-],  T,  S)  and  a  time  structure  T  on  TL,  this  predi¬ 
cate  is  recursively  defined  in  Figure  3,  where  we  have 
promoted  ^  to  denote  the  sub-interval  relation  over  T. 

Observe  that  me  defines  the  semantics  of  the  macro¬ 
event  constructors  presented  in  Definition  4.1.  In  the 
base  case  of  the  recursion,  i.e.  if  m  is  an  event  e,  we 
verify  if  an  ocurrence  of  e  has  been  recorded  in  the 
time-structure  T.  If  so,  we  check  that  it  takes  place 
over  a  subinterval  of  [ti,t2].  In  the  case  of  a  sequence, 
we  must  make  sure  that  the  endpoint  of  the  first  com¬ 
ponent  and  the  starting  time  of  the  second  are  within 
the  acceptable  delay.  Clearly,  they  must  take  place 
over  sequentially  disjoint  intervals.  In  order  to  verify 
that  an  alternative  macro-event  has  occurred,  we  look 
for  the  occurrence  of  either  component.  Parallel  macro¬ 
events  must  have  both  occurred  over  the  same  interval. 
Observe  that  we  do  not  require  that  the  two  branches 
mention  distinct  events;  indeed  m  ||  m  is  equivalent  to 
m.  Finally,  iterated  macro-events  are  essentially  re¬ 
duced  to  (possibly  empty)  sequences.  Notice  that  we 
do  not  force  any  form  of  maximality:  the  empty  iter¬ 
ation  is  always  satisfied;  its  starting  point  is  made  to 
coincide  with  the  beginning  of  the  test  interval,  and  it 
always  has  null  duration. 

We  check  whether  a  given  macro-event  has  occurred 
over  some  interval  by  using  the  above  definition,  while 
abstracting  from  the  starting  time  and  duration. 

Definition  4.3  ( Monitoring  Macro-Events ) 

Let  TL  be  a  MECTD-structure  and  T  be  a  time- 
structure  over  TL.  We  say  that  a  macro-event 
m  has  occurred  over  an  interval  [ti,t2],  written 
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check(m,  [ii,t2]),  iff 


3s,  l  G  T.  me(m,  [t\,  t2],s,  l ) 


is  valid. 


□ 


The  starting  point  and  duration  of  macro-events  are 
useful  in  order  to  compute  MVIs,  and  ultimately  to 
check  whether  a  given  property  holds  at  a  certain  point 
in  time.  Therefore,  me  offers  a  way  to  update  the  predi¬ 
cate  happens  from  Definition  3.5  to  operate  over  generic 
macro-events. 

Definition  4.4  ( MECTD-model) 

Let  Li  be  a  MECTD -structure  and  T  be  a  time- 
structure  over  Li.  We  modify  Definition  3.5  by  over¬ 
riding  the  definition  of  happens  given  there  with  the 
following  clause: 

happens(m,  t,  d)  iff  me(m,  [0,  oo],  i,  d)  □ 


This  definition  provides  an  elegant  specification  to 
the  core  of  the  system  presented  in  [10].  We  limited 
ourselves  to  treating  the  situation  where  macro-events 
can  initiate  or  terminate  properties.  This  is  sufficient 
for  many  applications,  and  involves  much  simpler  def¬ 
initions  than  the  general  case.  We  did  not  include 
here  the  possibility  of  a  macro-event  that  cancels  effects 
caused  by  some  of  its  components  (be  it  an  elementary 
event,  or  a  macro-event).  A  complete  specification  can 
be  found  in  [22],  and  will  be  included  in  an  extended 
version  of  this  paper. 

An  implementation  of  these  specifications  can  be 
found  in  Section  5.3. 


4.3  Example  —  Part  II 


Macro-events  are  a  convenient  tool  to  complete  the 
specification  of  the  example  in  Section  2.  Continuing 
from  Section  3.3,  we  can  now  express  the  validity  of 
properties  pilotOn,  pilotOff,  and  burning: 


[pilotOn]  •  (power,  gas)  = 

[pilotOff  |  •  |")  = 

[pilotOff  j  •  jpilotOn)  = 

[burning|  •  jpilotOn)  = 

[burning|  •  |cold,  power,  gas)  = 

{pilotOn  |  •  |  •]  = 

(pilotOff|- (power,  gas]  = 
(burning]  •  jpilotOn]  = 

{burning]  •  j]  = 


{prLighter  ||  prDisable} 
{start} 

{gasOff} 

{cool  Down} 

{prLighter  ||  prDisable} 

{gasOff} 

{prLighter  ||  prDisable} 
{warmUp} 

{gasOff} 


Property  burning  has  two  initiation  clauses.  The  first 
applies  when  the  pilot  light  is  lit:  if  the  temperature 


drops  below  the  thermostatic  threshold,  gas  will  start 
burning.  The  second  handles  the  case  where  the  room 
is  cold  at  the  moment  in  which  the  pilot  light  is  ignited. 
This  property  has  an  equally  interesting  termination 
behavior:  it  can  always  be  ended  by  cutting  the  gas 
supply,  but  if  the  pilot  light  is  on  it  is  sufficient  that 
the  room  temperature  warms  up  above  the  threshold 
set  through  the  thermostat. 

This  concludes  the  specification  of  the  properties  of 
interest. 

It  is  worth  observing  that  the  overall  specifica¬ 
tion  of  the  gas  heater  could  be  considerably  shortened 
by  admitting  the  notions  of  auto-initiation  and  auto¬ 
termination  [10]  to  our  calculus.  An  auto-initiated 
property  (here  burning  is  a  good  candidate)  is  explic¬ 
itly  initiated  not  by  the  occurrence  of  events,  but  as 
soon  as  the  validity  periods  of  one  or  more  other  prop¬ 
erties  start  overlapping  (here  pilotOn  and  cold).  Auto¬ 
termination  is  defined  in  a  dual  way.  We  plan  to  in¬ 
clude  these  constructs  in  a  forthcoming  version  of  the 
macro-event  calculus. 

5  Implementation 

We  will  now  give  a  Prolog  [25]  implementation  of 
the  calculi  we  have  presented  so  far  and  an  encoding  of 
our  case  study.  We  assume  the  reader  is  familiar  with 
this  logic  programming  language. 

5.1  EC  with  Explicit  Time 

We  represent  the  initiation  and  termination  maps, 
[•]•)  and  (•]•]  of  an  FCTD-structure  by  means  of  the 
Prolog  predicates  init  and  term,  respectively.  We  use 
Prolog’s  lists  to  represent  the  preconditions  of  the  ef¬ 
fect  of  an  event.  We  adopt  the  integers  as  the  temporal 
domain  T.  The  precedence  relation  -<  is  then  mapped 
to  <.  Each  pair  (e,  f)  in  a  time-structure  is  represented 
as  the  fact  happens ( ren ,rtn),  where  ren  and  rV  en¬ 
code  e  and  t.  respectively.  For  aesthetic  reasons,  we 
represent  an  interval  [fi.fo]  with  the  two-element  list 
[rIi\rf2n]. 

The  contents  of  Definition  3.3  are  then  transcribed 
as  follows  in  Prolog,  where  we  have  kept  the  predicate 
name  unchanged. 

holdsAt(P,  T)  : - 

mvi  (P ,  [T1  ,T2]  )  , 

T1  =<  T,  T  <  T2 . 

mvi(P,  [T1  ,T2] ) 

initiate (P,  Tl) ,  terminate (P,  T2) , 

T1  <  T2 , 

\+  broken(P,  [T1,T2]). 
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happens (E,  P) ,  lasts (E,  D) . 


mHoldsAt  ([],_). 
mHoldsAt ( [P I C]  ,  T) 
holdsAt(P,  T), 
mHoldsAt (C,  T) . 

initiate (P,  T) 

init (E ,  P,  C) , 
happens (E,  T) , 
mHoldsAt (C,  T) . 

terminate (P,T) 

term(E,  P,  C) , 
happens (E,  T) , 
mHoldsAt (C,  T) . 

broken (P,  [T1,T2]) 

(initiate (P,  T)  ;  terminate (P,  T)), 

T1  <  T,  T  <  T2 . 

Whenever  the  syntactic  conditions  [8]  mentioned  in 
Section  3.1  are  met,  this  program  allows  not  only  ver¬ 
ifying  the  validity  of  a  property  at  a  given  time  point 
t,  but  also  computing  all  the  properties  that  hold  at 
t.  Using  the  technique  in  [9],  it  is  possible  to  prove 
the  soundness  and  completeness  of  this  program  with 
respect  to  Definition  3.3. 

5.2  EC  with  Explicit  Time  and  Event  Duration 

We  add  one  argument  to  init  and  term  to  the  pre¬ 
vious  representation  to  encode  the  constraints  that  dis¬ 
tinguish  [-| -I-)  and  {-| -I-]  in  an  ECTD -structure.  More¬ 
over,  we  rely  on  Prolog's  arithmetic  to  emulate  the  op¬ 
eration  now  available  in  the  temporal  domain.  Finally, 
we  rely  on  the  predicate  lasts  to  model  the  duration 
function  6. 

The  behavior  of  ECTD  is  captured  by  replacing  the 
clauses  for  initiate  and  terminate  with  the  follow¬ 
ing  definitions,  and  adding  the  accessory  predicates 
happens,  mHoldsDuring, and  holdsDuring. 

initiate(P,TD) 

init(E,  P,  C,  K) , 
happens (E,  T,  D) , 

TD  is  T  +  D, 
mHoldsAt (C,  T) , 
mHoldsDuring (K,  [T,TD]). 

terminate (P,  TD) 

term(E,  P,  C,  K) , 
happens (E,  T,  D) , 

TD  is  T  +  D, 
mHoldsAt (C,  T) , 
mHoldsDuring (K,  [T,TD]). 

happens (E,  P,  D) 


mHoldsDuring (  []  ,  _)  . 
mHoldsDuring (  [P  |  C]  ,  I)  :  — 
holdsDuring (P,  I), 
mHoldsDuring(C,  I). 

holdsDuring (P,  [T1,T2]) 
mvi  (P ,  [T0,T3]  )  , 

TO  =<  Tl,  T2  =<  T3 . 

Again,  this  implementation  can  be  proved  sound  and 
complete  with  respect  to  Definition  3.4. 

5.3  Macro-Event  Calculus 

We  encode  the  process  constructions  m\  mjt 
mi  +  mo,  mi  ||  mo  and  m*  by  means 
of  the  Prolog  terms  seq(rmin  ,rmo”1  ,rcP  ,rZU), 
alt  (rmin  ,  rmon) ,  par  (rmin  ,  rmon) ,  and  it(rmn), 
respectively.  Lacking  a  better  abstraction,  we  used 
100000  for  oo. 

We  implement  the  predicate  me  and  Definitions  4.3- 

4.4  by  replacing  the  clause  for  happens/3  above  with 
the  following  code.  The  convoluted  definition  for 
subinterval  is  due  to  the  fact  that  it  is  used  both 
for  checking  that  an  interval  is  contained  in  another 
interval,  but  also  to  set  either  endpoints  of  the  former. 

me(E,  I,  S,  L) 

happens (E,  S) , 
lasts (E ,  L) , 

T  is  S  +  L, 

subinterval  (  [S  ,T]  ,  I). 

me  (seq(Ml  ,M2  ,  Min,  Max)  ,  [T1,T2],  S,  L) 
me  (Ml,  [Tl.Tll]  ,  S,  LI)  , 
me  (M2,  [T22.T2],  S2,  L2)  , 

S  +  LI  =<  Til,  Til  =<  T22 ,  T22  =<  S2 , 

Min  =<  (S2  -  S  -  LI),  (S2  -  S  -  LI)  =<  Max, 

L  is  S2  +  L2  -  S. 

me (alt (Ml, M2) ,  I,  S,  L) 

(me (Ml,  I,  S,  L)  ; 
me (M2,  I,  S,  L) ) . 

me (par (Ml, M2) ,  I,  S,  L) 
me (Ml,  I,  SI,  LI), 
me (M2,  I,  S2 ,  L2) , 

S  is  min(Sl ,S2) , 

L  is  max(Sl+Ll,S2+L2)  -  S. 

me  (it  (M)  ,  [T1,T2],  S,  L) 

me  (M,  [Tl  ,T]  ,  S,  LI), 
me  (it  (M)  ,  [T,T2],  S2,  L2)  , 

S+Ll  =<  T,  T  =<  S2 , 

L  is  S2  +  L2  -  S. 
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me  (it  (_)  ,  [T ,T]  ,  T,  0)  !. 

me  (it  (_)  ,  [T,_]  ,  T,  0). 

check(M,  I) 

me (M,  I,  _) . 

happens (M,  T,  D) 

me  (M,  [0,100000],  T,  D)  . 

subinterval (  [Bl, El]  ,  [B2,E2]) 

( (var  (B2)  ,  Bl  =  B2,  !)  ;  B2  =<  Bl)  , 

( (var (E2) ,  El  =  E2,  !)  ;  El  =<  E2) . 

Showing  the  soundness  and  completeness  of  this  im¬ 
plementation  with  respect  to  the  specifications  given  in 
Section  4.2  is  complicated  by  the  non-logical  implemen¬ 
tation  of  subinterval.  However,  once  this  predicate 
has  been  processed  in  isolation,  standard  techniques 
from  [9]  can  be  successfully  applied. 

5.4  Example  —  Part  III 

We  will  now  complete  the  treatment  of  the  gas- 
heater  example  by  displaying  the  clauses  that  encode 
the  associated  MECTD-structure  and  time  structure. 
The  latter  is  immediately  rendered  by  the  following 
facts: 


happens 

(start , 

0). 

happens (relDisable , 

6). 

happens 

(coolDown, 

0). 

happens (warmUp , 

8). 

happens 

(gasOn, 

1). 

happens (coolDown, 

10) 

happens 

(powerOn, 

2). 

happens (warmUp , 

11) 

happens 

(prDisable , 

3). 

happens (powerOf f , 

18) 

happens 

(prLighter , 

3). 

happens (gasOf f , 

19) 

happens 

(relLighter , 

5). 

happens (coolDown, 

25) 

where  we  have  kept  the  name  of  the  events  (and  below 
properties)  as  in  the  body  of  this  paper. 

In  our  example,  all  events  are  instantaneous.  There¬ 
fore,  the  clause 

lasts (E ,  0) . 

summarizes  all  the  relevant  information  about  event 
duration. 

The  initiation  and  termination  maps  relative  to  the 
gas  heater  problem  are  given  by  the  following  code, 
where  we  have  grouped  these  facts  by  the  property  be¬ 
ing  initiated  or  terminated: 


term(power0ff , 

power, 

□  , 

□  ). 

init(coolDown, 

cold, 

□  , 

□  ). 

term (warmUp , 

cold, 

□  , 

□  ). 

init(coolDown, 

thermo VOpen, 

□  , 

□  ). 

term (warmUp , 

thermo VOpen, 

□  , 

□  ). 

init (prLighter , 

sparking, 

□  , 

[power]  )  . 

term(relL ight  er , 

sparking , 

□  , 

□  ). 

term(power0ff , 

sparking , 

□  , 

□  ). 

init (prDisable , 

safety VOpen, 

□  , 

□  ). 

term(gas0ff , 

safety VOpen, 

□  , 

[pilotOn]  )  . 

term(relDisable , 

safety VOpen, 

□  , 

[pilotOff] )  . 

init(coolDown, 

burning, 

□  , 

[pilotOn]  )  . 

init (par (prLighti 

er, prDisable) , 
burning, 

□  , 

[cold, power ,gas] ) 

term (warmUp , 

burning, 

□  , 

[pilotOn]  )  . 

term(gas0ff , 

burning, 

□  , 

□  ). 

init (par (prLighti 

er, prDisable) , 
pilotOn, 

□  , 

[power ,  gas]  )  . 

term(gas0ff , 

pilotOn, 

□  , 

□  ). 

init (start , 

pilotOff , 

□  , 

□  ). 

init (gasOff , 

pilotOff , 

□  , 

[pilotOn]  )  . 

term(par (prLighti 

er, prDisable) , 
pilotOff , 

□  , 

[power ,  gas]  )  . 

This  completes  the  formalization  of  the  gas  heater. 
We  can  now  use  it  to  extract  information  that  is  im¬ 
plicit  in  the  example.  The  following  query  retrieves  the 
maximum  validity  intervals  of  all  the  properties  that 
appear  in  this  case  study. 

?-  mvi (M,  I) . 


M  = 

gas 

I 

= 

[1,  19] 

M  = 

power 

I 

= 

[2,  18] 

M  = 

cold 

I 

= 

[0,  8] 

M  = 

cold 

I 

= 

[10,  11] 

M  = 

thermo VOpen 

I 

= 

[0,  8] 

M  = 

thermo VOpen 

I 

— 

[10,  11] 

M  = 

sparking 

I 

= 

[3,  5] 

M  = 

safetyVOpen 

I 

= 

[3,  19] 

M  = 

burning 

I 

= 

[10,  11] 

M  = 

burning 

I 

— 

[3,  8] 

M  = 

pilotOn 

I 

= 

[3,  19] 

init (gasOn, 
term(gas0ff , 


gas, 

gas, 


□  ,  □). 
□  ,  □). 


init (powerOn,  power, 


□  ,  □). 
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M  =  pilotOff 


I  =  [0,  3]  ; 

No 

We  can  also  inquire  whether  a  given  macro-event  has 
occurred,  when  it  started,  and  how  long  it  lasted.  For 
example,  if  we  want  to  know  if  it  ever  happened  that 
the  room  first  got  cold  and  then  warm  within  20  time 
units,  the  following  query  will  provide  three  answers: 

?-  happens (seq(coolDown, warmUp , 0, 20)  ,  T,D  ). 

T  =  0  D  =  8  ; 

T  =  0  D  =  11  ; 

T  =  10  D  =  1  ; 

No 

Observe  that  the  first  interval  embeds  the  second.  This 
is  acceptable  since,  differently  from  the  evaluation  of 
MW-goals,  queries  about  macro-events  do  not  involve 
maximality  checks. 

Finally,  we  show  a  use  of  the  predicate  check,  which 
verifies  whether  a  given  macro-event  has  occurred  in  a 
given  interval. 

?-  check(seq(coolDown, warmUp , 1 , 5) ,  [3,19]). 

Yes 

6  Conclusions  and  Future  Work 

In  this  paper,  we  presented  a  preliminary  attempt 
at  defining  a  Calculus  of  Macro-Events  that  extends 
Kowalski  and  Sergot’s  Event  Calculus  with  primitives 
(process  constructors)  for  modeling  discrete  processes. 
In  particular,  we  showed  how  to  infer  the  occurrence  of 
macro-events  from  the  occurrence  of  their  atomic  com¬ 
ponents  (monitoring)  as  well  as  how  to  derive  the  maxi¬ 
mal  validity  intervals  of  properties  initiated  and/or  ter¬ 
minated  by  a  given  set  of  macro-events  (evaluation). 
Furthermore,  the  expressive  power  of  the  Macro-Event 
Calculus  has  been  demonstrated  through  the  encoding 
of  a  simple  real-world  example  (a  more  complex  exam¬ 
ple,  namely  the  formalization  of  the  Dagstuhl  steam- 
boiler  control  specification  problem  [1],  has  been  im¬ 
plemented  using  a  superset  of  our  proposal  in  [22]). 

We  are  investigating  ways  to  extend  this  work  to 
naturally  capture  finer  process  constructors,  in  partic¬ 
ular  definitions,  non-occurrence,  and  exclusive  alter¬ 
natives.  This  would  allow,  for  example,  a  complete 
specification  of  the  gas  heater  problem.  We  are  also 
interested  in  formalizing  synergetic  effects  and  interfer¬ 
ence  [22] .  Finally,  we  are  currently  working  at  properly 


establishing  the  expressiveness  and  complexity  of  vari¬ 
ants  of  the  Macro-Event  Calculus  and  at  systematically 
comparing  them  with  other  formalisms  for  discrete  pro¬ 
cess  modeling  proposed  in  the  literature. 
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